Frontend Micro-Frontend Router: Navigation på tværs af applikationer

I moderne webudvikling har micro-frontend arkitekturen vundet betydelig fremdrift som en måde at bygge store, komplekse applikationer på. Det indebærer at nedbryde en monolitisk frontend i mindre, uafhængige og deploybare enheder (micro-frontends). En af de centrale udfordringer i denne arkitektur er at administrere navigation på tværs af applikationer, så brugerne problemfrit kan bevæge sig mellem disse uafhængige micro-frontends. Denne artikel giver en omfattende guide til frontend micro-frontend routing og navigation på tværs af applikationer.

Hvad er Micro-Frontends?

Micro-frontends er en arkitektonisk stil, hvor uafhængigt leverbare frontend-applikationer er sammensat til en enkelt, sammenhængende brugeroplevelse. Dette er analogt med mikrotjenester i backend. Hver micro-frontend er typisk ejet af et separat team, hvilket giver større autonomi, hurtigere udviklingscyklusser og lettere vedligeholdelse. Fordelene ved micro-frontends inkluderer:

• Uafhængig implementering: Teams kan implementere deres micro-frontends uden at påvirke andre dele af applikationen.
• Teknologisk diversitet: Forskellige micro-frontends kan bygges ved hjælp af forskellige teknologier, hvilket giver teams mulighed for at vælge det bedste værktøj til jobbet. For eksempel kan et team bruge React, mens et andet bruger Vue.js eller Angular.
• Skalerbarhed: Applikationen kan skalere lettere, da hver micro-frontend kan skaleres uafhængigt.
• Forbedret vedligeholdelse: Mindre kodebaser er lettere at forstå og vedligeholde.
• Teamautonomi: Teams har mere kontrol over deres egen kode og udviklingsproces.

Behovet for en Micro-Frontend Router

Uden en veldefineret routingstrategi vil brugerne opleve en usammenhængende og frustrerende oplevelse, når de navigerer mellem micro-frontends. En micro-frontend router adresserer dette ved at levere en centraliseret mekanisme til at administrere navigation på tværs af hele applikationen. Dette inkluderer håndtering af:

• URL-administration: Sikring af, at URL'en nøjagtigt afspejler brugerens aktuelle placering i applikationen.
• Statushåndtering: Deling af status mellem micro-frontends, når det er nødvendigt.
• Lazy Loading: Indlæsning af micro-frontends, kun når de er nødvendige for at forbedre ydeevnen.
• Godkendelse og autorisation: Håndtering af brugergodkendelse og -autorisation på tværs af forskellige micro-frontends.

Navigationsstrategier på tværs af applikationer

Der er flere tilgange til at implementere navigation på tværs af applikationer i en micro-frontend arkitektur. Hver tilgang har sine egne fordele og ulemper, og det bedste valg afhænger af de specifikke krav til din applikation.

1. Brug af en centraliseret router (Single-Spa)

Single-Spa er en populær ramme for at bygge micro-frontends. Den bruger en centraliseret router til at administrere navigation mellem forskellige applikationer. Hovedapplikationen fungerer som orkestratoren og er ansvarlig for at gengive og afmontere micro-frontends baseret på den aktuelle URL.

Sådan fungerer det:

1. Brugeren navigerer til en bestemt URL.
2. Single-spa routeren opfanger URL-ændringen.
3. Baseret på URL'en bestemmer routeren, hvilken micro-frontend der skal være aktiv.
4. Routeren aktiverer den tilsvarende micro-frontend og afmonterer eventuelle andre aktive micro-frontends.

Eksempel (Single-Spa):

Lad os sige, at du har tre micro-frontends: hjem, produkter og kurv. Single-spa routeren vil blive konfigureret som følger:

import { registerApplication, start } from 'single-spa'; registerApplication( 'hjem', () => import('./home/home.app.js'), location => location.pathname === '/' ); registerApplication( 'produkter', () => import('./products/products.app.js'), location => location.pathname.startsWith('/products') ); registerApplication( 'kurv', () => import('./cart/cart.app.js'), location => location.pathname.startsWith('/cart') ); start();

I dette eksempel er hver micro-frontend registreret med single-spa, og der er angivet en funktion til at bestemme, hvornår micro-frontend skal være aktiv baseret på URL'en. Når brugeren navigerer til /produkter, vil produkter micro-frontend blive aktiveret.

Fordele:

• Centraliseret kontrol over routing.
• Forenklet statushåndtering (kan håndteres af single-spa orkestratoren).
• Let at integrere med eksisterende applikationer.

Ulemper:

• Enkelt fejlpunkt. Hvis orkestratoren går ned, påvirkes hele applikationen.
• Kan blive en præstationsflaskehals, hvis den ikke implementeres effektivt.

2. Module Federation (Webpack 5)

Webpack 5's Module Federation giver dig mulighed for at dele kode mellem forskellige Webpack-builds ved runtime. Dette betyder, at du kan eksponere komponenter, moduler eller endda hele applikationer fra et build (værten) til et andet (fjern). Dette letter opbygningen af micro-frontends, hvor hver micro-frontend er et separat Webpack-build.

Sådan fungerer det:

1. Hver micro-frontend er bygget som et separat Webpack-projekt.
2. En micro-frontend er udpeget som værtapplikationen.
3. Værtapplikationen definerer, hvilke moduler den ønsker at forbruge fra de fjernede micro-frontends.
4. De fjernede micro-frontends definerer, hvilke moduler de vil eksponere for værtapplikationen.
5. Ved runtime indlæser værtapplikationen de eksponerede moduler fra de fjernede micro-frontends efter behov.

Eksempel (Module Federation):

Antag en vært app og en fjern app.

host/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { remote: 'remote@http://localhost:3001/remoteEntry.js', }, shared: ['react', 'react-dom'], }), ], };

remote/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'remote', exposes: { './Button': './src/Button', }, shared: ['react', 'react-dom'], }), ], };

I dette eksempel forbruger vært applikationen Button-komponenten fra fjern applikationen. shared-indstillingen sikrer, at begge applikationer bruger den samme version af react og react-dom.

Fordele:

• Decentraliseret arkitektur. Hver micro-frontend er uafhængig og kan udvikles og implementeres separat.
• Kodedeling. Module Federation giver dig mulighed for at dele kode mellem forskellige applikationer ved runtime.
• Lazy loading. Moduler indlæses kun, når de er nødvendige, hvilket forbedrer ydeevnen.

Ulemper:

• Mere komplekst at opsætte og konfigurere end single-spa.
• Kræver omhyggelig styring af delte afhængigheder for at undgå versionskonflikter.

3. Webkomponenter

Webkomponenter er et sæt webstandarder, der giver dig mulighed for at oprette genanvendelige brugerdefinerede HTML-elementer. Disse komponenter kan bruges i enhver webapplikation, uanset hvilket framework der bruges. Dette gør dem til en naturlig pasform til micro-frontend arkitekturer, da de giver en teknologiafhængig måde at bygge og dele UI-komponenter på.

Sådan fungerer det:

1. Hver micro-frontend eksponerer sin UI som et sæt Webkomponenter.
2. Hovedapplikationen (eller en anden micro-frontend) bruger disse Webkomponenter ved at importere dem og bruge dem i sin HTML.
3. Webkomponenterne håndterer deres egen gengivelse og logik.

Eksempel (Webkomponenter):

micro-frontend-a.js:

class MyComponent extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); this.shadowRoot.innerHTML = `

Hej fra Micro-Frontend A!

`; } } customElements.define('micro-frontend-a', MyComponent);

index.html (hovedapplikation):

Hovedapplikation

I dette eksempel definerer filen micro-frontend-a.js en Webkomponent kaldet micro-frontend-a. Filen index.html importerer denne fil og bruger Webkomponenten i sin HTML. Browseren gengiver Webkomponenten og viser "Hej fra Micro-Frontend A!".

Fordele:

• Teknologiafhængig. Webkomponenter kan bruges med ethvert framework eller intet framework overhovedet.
• Genanvendelighed. Webkomponenter kan nemt genbruges på tværs af forskellige applikationer.
• Indkapsling. Webkomponenter indkapsler deres egne stilarter og logik, hvilket forhindrer konflikter med andre dele af applikationen.

Ulemper:

• Kan være mere omstændeligt at implementere end andre tilgange.
• Kan kræve polyfills for at understøtte ældre browsere.

4. Iframes

Iframes (Inline Frames) er en ældre, men stadig levedygtig mulighed for at isolere micro-frontends. Hver micro-frontend kører inden for sin egen iframe, hvilket giver en høj grad af isolation. Kommunikation mellem iframes kan opnås ved hjælp af postMessage API'en.

Sådan fungerer det:

1. Hver micro-frontend implementeres som en separat webapplikation.
2. Hovedapplikationen indeholder hver micro-frontend i en iframe.
3. Kommunikation mellem hovedapplikationen og micro-frontends sker ved hjælp af postMessage API'en.

Eksempel (Iframes):

index.html (hovedapplikation):

Hovedapplikation

I dette eksempel indeholder filen index.html to iframes, der hver peger på en anden micro-frontend.

Fordele:

• Høj grad af isolation. Micro-frontends er fuldstændig isoleret fra hinanden, hvilket forhindrer konflikter.
• Let at implementere. Iframes er en enkel og velkendt teknologi.

Ulemper:

• Kan være svært at kommunikere mellem iframes.
• Kan have ydeevneproblemer på grund af omkostningerne ved flere iframes.
• Dårlig brugeroplevelse på grund af manglen på problemfri integration.

Statushåndtering på tværs af Micro-Frontends

Administrering af status på tværs af micro-frontends er et kritisk aspekt af navigation på tværs af applikationer. Der kan anvendes flere strategier:

• URL-baseret status: Kodning af status inden for URL'en. Denne tilgang gør applikationstilstanden delbar via URL'er og let bogmærkevenlig.
• Centraliseret statushåndtering (Redux, Vuex): Brug af et globalt statushåndteringsbibliotek til at dele status mellem micro-frontends. Dette er især nyttigt for komplekse applikationer med betydelig delt status.
• Brugerdefinerede begivenheder: Brug af brugerdefinerede begivenheder til at kommunikere statusændringer mellem micro-frontends. Denne tilgang giver mulighed for løs kobling mellem micro-frontends.
• Browserlagring (LocalStorage, SessionStorage): Lagring af status i browserlagring. Denne tilgang er velegnet til enkel status, der ikke behøver at blive delt på tværs af alle micro-frontends. Vær dog opmærksom på sikkerhedsmæssige overvejelser ved lagring af følsomme data.

Godkendelse og autorisation

Godkendelse og autorisation er afgørende aspekter af enhver webapplikation, og de bliver endnu vigtigere i en micro-frontend arkitektur. Almindelige tilgange inkluderer:

• Centraliseret godkendelsestjeneste: En dedikeret tjeneste håndterer brugergodkendelse og udsteder tokens (f.eks. JWT). Micro-frontends kan derefter validere disse tokens for at bestemme brugerautorisation.
• Delt godkendelsesmodul: Et delt modul er ansvarligt for at håndtere godkendelseslogik. Dette modul kan bruges af alle micro-frontends.
• Edge-godkendelse: Godkendelse håndteres i udkanten af netværket (f.eks. ved hjælp af en omvendt proxy eller API-gateway). Denne tilgang kan forenkle godkendelseslogikken i micro-frontends.

Bedste praksis for Micro-Frontend Routing

Her er nogle bedste praksis, du skal huske på, når du implementerer micro-frontend routing:

• Hold det enkelt: Vælg den enkleste routingstrategi, der opfylder dine behov.
• Frakobl Micro-Frontends: Minimer afhængigheder mellem micro-frontends for at fremme uafhængig udvikling og implementering.
• Brug en ensartet URL-struktur: Oprethold en ensartet URL-struktur på tværs af alle micro-frontends for at forbedre brugeroplevelsen og SEO.
• Implementer Lazy Loading: Indlæs micro-frontends kun, når de er nødvendige for at forbedre ydeevnen.
• Overvåg ydeevnen: Overvåg regelmæssigt ydeevnen af din micro-frontend applikation for at identificere og adressere eventuelle flaskehalse.
• Etabler klare kommunikationskanaler: Sørg for, at teams, der arbejder på forskellige micro-frontends, har klare kommunikationskanaler for at koordinere udviklingsindsatsen og løse eventuelle integrationsproblemer.
• Implementer robust fejlhåndtering: Implementer robust fejlhåndtering for på en elegant måde at håndtere fejl i individuelle micro-frontends og forhindre dem i at påvirke hele applikationen.
• Automatiseret test: Implementer omfattende automatiseret test, inklusive enhedstest, integrationstest og end-to-end-tests, for at sikre kvaliteten og stabiliteten af din micro-frontend applikation.

Konklusion

Micro-frontend routing er et komplekst, men essentielt aspekt af at bygge skalerbare og vedligeholdelsesvenlige webapplikationer. Ved omhyggeligt at overveje de forskellige routingstrategier og bedste praksis, der er skitseret i denne artikel, kan du skabe en problemfri og brugervenlig oplevelse for dine brugere. Valg af den rigtige tilgang, uanset om det er en centraliseret router som Single-Spa, Module Federation, Web Components eller endda Iframes, afhænger af dine specifikke behov og prioriteter. Husk at prioritere frakobling, ensartede URL-strukturer og optimering af ydeevnen. Ved at implementere en velfungerende routingstrategi kan du frigøre det fulde potentiale i micro-frontend arkitekturen og bygge virkelig exceptionelle webapplikationer for et globalt publikum.